Whack A Mole

In QMC, a central role is given to the local energy, defined as (1/psi)H psi, where psi is the trial wave function. If psi is an eigenstate, then H psi = E psi by definition, and the local energy becomes a constant. Just as lower energy trial functions are deemed better than higher energy ones, those with fewer fluctutations are better than those with more fluctutations.

One could imagine looking at the fluctuations in the local energy, and using those to determine where best to adjust the trial wave function to reduce the fluctutations (side note: one would want to use psi^2 times the local energy, since fluctuations are weighted by psi^2 in the integrals). This seems similar to the game of Whack-A-Mole, where one attempts to hit mechanical moles that pop up randomly for a brief period of time. Maybe the method could be called Whack-A-Local-Energy (WHALE).

Unfortunately for my naming scheme (and fortunately for everyone else), the method described already exists, and it's called the Energy Fluctutation Potential (EFP) method. It was first described by Stephen Fahy in "Quantum Monte Carlo Methods in Physics and Chemistry" [NATO ASI Ser. C 525 101, 1999; M. P. Nightingale and C. J. Umrigar, eds]. Further papers describing the method:

• Optimal orbitals from energy fluctuations in correlated wave functions, by Fahy and Filippi
  
• Optimization of inhomogeneous electron correlation factors in periodic solids by Prendergast, Bevan, and Fahy
  
• Optimized Jastrow-Slater wave functions for ground and excited states: Application to the lowest states of ethene by Schautz and Filippi
  

The EFP method involves an iteration that starts with a one-body solver (HF or LDA). The resulting orbitals are used in a VMC calculation, and the fluctuations in the local energy form a extra potential that is fed back into the one-body solver to get new orbitals, and the iteration repeats until a self-consistent solution is reached.

(Name note: this paper by Umrigar and Filippi calls it the Effective Fluctuation Potential method. This paper also gives another reference I didn't put on the above list)

Store, manage, and share your reading list

The cleverly-named del.icio.us site describes itself as "social bookmarks." The "bookmarks" part allows users to keep track of links online, include a short description, and add an arbitrary number of one-word tags to help categorize the link. With the
"social" part, people's bookmarks are available to everone else.


Here's my list of bookmarks. (I just started, it's not very large)

For the academic world, Richard Cameron created CiteULike. It allows assigning category tags to papers, and has the social aspect of sharing links to papers. Perhaps most importantly, it can automatically import bibliographic information from supported publishers (including arXiv) and export the information to other formats (BibTex, EndNote).


Here's my list of articles. (Once again, very small so far)

The link to CiteULike was found via Corante

I don't know whether either of these will be a useful tool for research, but it seems worthwhile to try them out. When I started grad school in 1993, I went to the library to photocopy articles. By the time I finished in 2000, I went to the library website to download articles. That seems like a large shift, but I suspect it's not just because it makes it faster and more efficient to get the articles - it's the linking, management, and annotations represented by these sorts of applications that will make a bigger change in the future.

MathMath

A wiki seems like a good way to organize information. Blogs work nice for recording thoughts and links in chronological order, but aren't so good for organizing ideas topically or for revising items. Proto-papers or latex files with background information have been used. The easily edited environment of a wiki seems like it would function well, even if were only used personally (part of the wiki idea is open collaborative editing). The wiki text markup is much lighter than HTML, so it would be easier to deal with than maintaining a set of web pages.

The real issue is integrating mathematics. Mozilla and derivatives can handle MathML (and IE can with a plugin), so that seems like a good route (inserting pictures is marginally okay for converting papers to HTML, but is not as good for a more interactive environment). The only problem with MathML is the rapid onset of RSI if you actually write equations with it.

There are a couple of solutions, both convert TeX or vaguely TeX-like input to MathML. They are itex2mml and AsciiMathML. The second solution seems rather nice, as it uses javascript to convert the TeX-like notation to MathML when the page loads into the browser.

For a wiki, I've been looking into MoinMoin. At first I tried hacking itex2mml into it, and it took quite a few changes to make everything proper XHTML. Then I found the page that describes integrating AsciiMathML into MoinMoin, and that was much smoother.

AsciiMathML also has a nice way of adding new symbols, that doesn't require changing the AsciiMathML.js file.
In keeping with title of this weblog, the Unicode number for hbar is 0x210F. (although it usually only appears once in a paper and is promptly set to "1") The code for adding it is

<script type="text/javascript">
AMsymbols = AMsymbols.concat([
{input:"hbar", tag:"mo", output:"\u210F", tex:"hbar"}
]);
</script>